The replication of data objects is well known to every user of a computer and is a standard procedure that is routinely applied. A special application of replicating data objects is the copying or the archiving process, by which data objects are copied from a source system to a target system for safety and/or performance reasons. In these special applications, the data objects may remain unchanged. However, the more general term “replication” may also comprise processes in which the data objects are changed during the replication process. Such changes may be a consequence of the need to concentrate the amount of data or of a desire of the user of the target system to receive only a particular part of the data object.
In enterprises, so called enterprise resource planning software (ERP) applications are used to control business processes and to manage company information of enterprises of various kinds in any field of technology by means of automatic data processing systems such as computers or computer systems. During the use of such software, a huge amount of data is usually created, which contains important business information contained in data objects. In such an environment a source system may be the computer and software system of the financial and or controlling department, and the target system may be the computer and software system of the management.
In order to keep the management informed about the economic situation in the enterprise, e.g. financial data, posting data may be replicated (transferred under changes such as aggregations or concentrations or copied) from the financial system to the management system. In many ERP applications, the transactions of the enterprise are stored in the computer system independently and at any time. At the same time, there is a need to provide one or more target systems with replicated data. These data replications usually take place less frequently, and in order to reduce the amount of the transferred data volume, only data objects which are new or amended since the previous replication process may be replicated. One method to reach this goal is the time stamp process. In this method, a time stamp is assigned to the data object to be stored in the source system. The time stamp is usually the time at which the data object is stored or a time shortly after the storage process has started. And a replication application, a software application that replicates the data object from the source to the target system, replicates at a particular run data objects whose time stamps are within a particular, predefinable time interval.
However, this method has the disadvantage that the time stamp is not necessarily identical with time of the actual commit of the data base (application), which physically stores/writes the data object on the physical storage means. This discrepancy may cause failures, particularly missing data objects, in the replication process if the replication process takes place at a time between the time stamp and the time of the commit or if the storing and replication processes run parallel. Suppose a time stamp tS, a commit tC, and a replication interval from t1 to t2, where t1<tS<t2<tC. In such a time gap, the particular data object is, due to the lacking commit (t2<tC), not yet visible for the replication application and will thus not be replicated. During the next replication run with an interval from t2 to t3 the time stamp of that data object is not within the interval because of tS<t2. This problem is usually defused by using a time t2+Δt as the upper level of the replication interval and starting the subsequent replication run exactly at t2. A usual length of Δt is about 30 min. However, this concept with Δt has, on the one hand, the disadvantage that “historical” data objects are replicated if Δt is too large and, on the other hand, that data objects are lost if Δt is too small. Further, assigning a time stamp is an access on a central resource of the computer and disturbs the parallel storing of the data objects.